iT邦幫忙

system design相關文章
共有 48 則文章
鐵人賽 Software Development DAY 22

技術 Day 22 深入探討 Search System

我們的 PokeThreads 走到現在,已經是一個具備 Load Balancer、Stateless Server、Sharded Database、Cac...

鐵人賽 Software Development DAY 21

技術 Day 21 一個人讓系統爆炸:Hot User 與 Hot Post

昨天在討論 Fan-out 時提到,擁有幾千萬追蹤者的帳號一發文,就可能讓 Fan-out on Write 的寫入量瞬間爆炸,所以今天就把這個狀況抽出來單獨討...

鐵人賽 Software Development DAY 20

技術 Day 20 Feed 走向大型系統的 Fan-out 做法

今天回頭加強 Feed 功能,看看原本陽春的做法會有什麼問題。 先回顧原本的做法 Day 3 我們做出了最陽春的 Feed 邏輯: SELECT * FROM...

鐵人賽 Software Development DAY 19

技術 Day 19 深入探討 Follow 功能

昨天把 Database 拆成多個 Shard,解決了單一 Database 裝不下所有資料的問題。 今天把這個概念套用在一個具體場景上——Follow 功能,...

鐵人賽 Software Development DAY 18

技術 Day 18 Database Sharding

Day 17 用 CAP Theorem 收尾時提到一句話:這條線會一路貫穿到後面 Sharding、Counter System 這些主題。今天就從 Shar...

鐵人賽 Software Development DAY 17

技術 Day 17 CAP Theorem - 你無法全都要

昨天討論 SQL 該不該換成 NoSQL,最後留下一個疑問,一旦資料開始分散在不同種類的 Storage 上,SQL、NoSQL、Cache 各存一部分。 怎...

鐵人賽 Software Development DAY 16

技術 Day 16 資料庫是否該用 NoSQL

PokeThreads 走到今天,已經不是一個單純的 CRUD 小玩具了,但從 Day 2 開始,Database 一直都是同一種選擇,也就是 SQL。這時候很...

鐵人賽 Software Development DAY 15

技術 Day 15 Rate Limiter 控制流量

昨天在 API Gateway 的職責清單裡,提到它很適合順便做 Rate Limiting,但只是輕輕帶過。今天把這件事攤開來講清楚。 為什麼需要限制流量 限...

鐵人賽 Software Development DAY 14

技術 Day 14 API Gateway 負責引導

昨天把 Notification 從 PokeThreads 的 Monolith 拆成了獨立的 Notification Service,跟原本的 API S...

鐵人賽 Software Development DAY 13

技術 Day 13 Monolith vs Microservices

到目前為止,PokeThreads 已經具備了 Load Balancer、Read Replica、Cache、Stateless Server、CDN 與...

鐵人賽 Software Development DAY 12

技術 Day 12 Message Queue 不讓客人等

昨天做出了最陽春的 Notification System,採用最直接的同步方式: Charmander -> POST /posts/:id/like...

鐵人賽 Software Development DAY 11

技術 Day 11 Notification System 初型

前面幾天,PokeThreads 的架構已經慢慢演化成分散式系統,不過所有功能都還圍繞在「發文、讀文」上。 只有這麼簡單的功能,實在太像古早時期的社群網站,今天...

鐵人賽 AI Engineering DAY 16

技術 Day 16|Skill:把流程寫成一份可以維護的檔案

Day 15 定義了五個角色——誰來做。這一篇講怎麼做:那些反覆執行的流程,被寫成一份一份的 Skill 檔案。 第三代我保留了 Spec Kit 的骨架,...

鐵人賽 Software Development DAY 10

技術 Day 10 Media Pipeline 上傳一張圖片,中間發生了什麼事?

昨天把 CDN 接上了 PokeThreads,圖片跟影片不再經過 Application Server,直接由 CDN 搭配 Object Storage 提...

鐵人賽 AI Engineering DAY 15

技術 Day 15|Frontend、API、QA、Security、Documentation:agent 角色定義

六月底那一天,我把需求文件裡的 11 項分完類、安排執行順序後,回頭想,指揮中心能把工作分批、判斷誰跟誰能平行做,是使用我定義好的 Agent —— Front...

鐵人賽 Software Development DAY 9

技術 Day 9 運用 CDN 處理多媒體素材

前面幾天,PokeThreads 的架構已經逐漸長成分散式系統的樣子,但焦點始終放在文字貼文要怎麼被處理跟讀取,現在想加入一個很自然的新功能:讓使用者也能上傳圖...

鐵人賽 AI Engineering DAY 14

技術 Day 14|六月底那一週:一條流程,只做一個功能,這樣可以如何加速

六月底的一天,我開始陸續調整畫面,那次在一份需求文件上一次列了11個要調整的地方項目。多數是文字調整或小 bug:欄位文字要改、某個預設值該拿掉、確認頁該顯示姓...

鐵人賽 Software Development DAY 8

技術 Day 8 Cache 讓你不用每次都要讀 Database

目前 PokeThreads 的架構已經有多台 Server 和 Primary / Replica Database: Read 壓力被 Replica 分...

鐵人賽 Software Development DAY 7

技術 Day 7 一顆 Database 不夠用:Database Replication

前幾天把 Application Server 從一台變成多台,也把 Session 從 Server Memory 搬到共用的 Session Store:...

鐵人賽 AI Engineering DAY 12

技術 Day 12|Step 7:加上資安審查步驟

Day 11 我把功能驗收寫成 Scenario,讓 LLM 透過 Playwright MCP 依照前置條件操作頁面。Scenario 確認的是:使用者依既定...

鐵人賽 Software Development DAY 6

技術 Day 6 Session 要放哪?

昨天我們把 Application Server 從一台擴展成多台,靠 Load Balancer 分攤流量: 這解決了單台 Server 的容量問題,但當時...

鐵人賽 Software Development DAY 5

技術 Day 5 一台 Server 不夠用:Vertical Scaling vs Horizontal Scaling

這幾天我們把最陽春的 PokeThreads 做出來了,也解決了 Feed 該回傳什麼內容的問題,但整個架構其實還停留在最原始的狀態: 瀏覽器 -> Se...

鐵人賽 Software Development DAY 4

技術 Day 4 REST vs GraphQL:前後端到底該怎麼聊天?

昨天把 Feed 的核心邏輯做出來了,GET /feed 已經能正確回傳 Pikachu 追蹤的人發的貼文,但那時候刻意跳過了一個問題:這支 API 到底該回傳...

鐵人賽 Software Development DAY 3

技術 Day 3 Feed 怎麼產生?

昨天做出了最陽春的 PokeThreads,但故意跳過了一個問題: GET /feed 這支 API 收到 Request 之後,到底該回傳哪些貼文? Fee...

鐵人賽 Software Development DAY 2

技術 Day 2 設計最簡單的社群網站

上一篇估算出來的流量其實非常小,每秒寫入大概 1~2 次、讀取大概 100 多次,這種規模不需要任何花俏的架構,先做出一個 「堪用」 的版本就好。 這也是這個系...

鐵人賽 Software Development DAY 1

技術 Day 1 什麼是軟體系統設計?

這系列文章想陪大家一起做一件事:從零開始設計一個名為 PokeThreads 的社群平台(參考自 Meta 的 Threads),並且讓它隨著使用者變多、流量變...

技術 你可能高估 AI Agent 了:先搞懂它,再談 Agent Systems

為什麼現在大家都在談 AI Agent? 這兩年,AI Agent 幾乎變成生成式 AI 世界裡最熱門的詞之一,但越熱門的詞,往往也越容易被混用,有些人說 A...

技術 [閱讀紀錄-系統設計] 天馬行空限制器,定義功能性需求與非功能性需求

功能性需求(Funtional Requirements) 描述各種系統該做的事,如系統該提供使用者查詢影片(Youtube),提供使用者建立文章(IT邦)。...

技術 System Design Interview Ch 12 Digital Wallet

完整內容,請至幹話王 System Design Interview Ch 12 Digital Wallet 本文內容的章節是來自內行人才知道的系統設計面試指...

鐵人賽 Cloud Native DAY 20

技術 Gthulhu API Server Design

如果覺得文章對你有所啟發,可以考慮用 🌟 支持 Gthulhu 專案,短期目標是集齊 300 個 🌟 藉此被 CNCF Landscape 採納 [ref]。...